The present invention relates to the control of access to operating systems sent by a server computer system to a client computer system in response to a request by the client computer system utilizing a pre-execution logon verification of user identification and password and override of the Universally Administered Address (UAA) by a locally Administered Address (LAA) corresponding to the boot package to be sent to the client workstation.
A computer or computer system, when turned on, must be prepared for operation by loading an operating system. In the normal operation of a single computer system, when a user issues a boot command to the computer, the computer responds to the boot command by attempting to retrieve the operating system files from the computer systems memory. Configuration data files are also needed to configure the specific machine with the hardware parameters necessary for the specific hardware configuration. These files also contain information needed to initialize videos, printers, and peripherals associated with the particular machine. For example, the files would include CONFIG.SYS in the MS-DOS operating system, available from Microsoft Corporation.
Computers or computer systems can be connected in a network normally consisting of a client workstation, a server and a central network. In a system where the computer""s storage is maintained when the power is turned off, the operating system can be stored in the computer itself In a system where the computer has only storage that is lost when the power is turned off, the computer cannot retrieve the boot information from within the computer itself In that case, the client sends a request for the operating system files via the network to the server acting as a boot server. Even when the client workstation has non-volatile storage capability, it is advantageous to boot from the server because memory space is saved in the workstation computer. As operating system and application programs expand to provide new and greater capabilities, booting from a server can be highly advantageous.
Several methods of remote booting exist in the marketplace. One is called Remote Initial Program Load (RIPL). RIIPL is the process of loading an operating system onto a workstation from a remote location. The RIPL protocol was co-developed by 3Com, Microsoft, and IBM. It is used today with IBM OS/2 Warp Server, DEC Pathworks, and Windows NT. Two other commonly used Remote IPL protocols are a Novell NCP (NetWare Core Protocol), and BOOT-P, an IEEE standard, used with UNIX and TCP/IP networks.
RIPL is achieved using a combination of hardware and software. The requesting device, called the requester or workstation, starts up by asking the loading device to send it a bootstrap program. The loading device is another computer that has a hard disk and is called the RIPL server or file server. The RIPL server uses a loader program to send the bootstrap program to the workstation. Once the workstation receives the bootstrap program, it is then equipped to request an operating system, which in turn can request and use application programs. The software implementations differ between vendors, but theoretically, they all perform similar functions and go through a similar process. The client workstation requires a special Read Only Memory (ROM) installed on its (Local Area Network) LAN adapter or Network Interface Card (NIC). The special ROM is known generally as a remote boot ROM, but two specific examples of remote boot chips are the RIPL chip, which supports ANSI/IEEE standard 802.2, and the Preboot Execution Environment (PXE) chip, which is used in the Transmission Control Protocol/Internet Protocol (TCP/IP) environment.
While the process has many advantages for booting a computer that has volatile storage, such as a network computer, the computer is required to have a remote boot ROM on the LAN adapter or Network Interface Card (NIC). The remote boot ROM requirement does not allow any user interaction with the remote boot process.
Application Ser. No. 09/389,440 now U.S. Pat. No. 6,539,473 B1 discloscs a remote client boot allowing a client computer to boot from a server without the remote boot ROM requirement.
The client""s Media Access Control (MAC) address is the key factor that determines many characteristics of the boot process. The MAC address determines what server the client will boot from, what operating system will be loaded and what the client""s computers configuration will be.
A need arises in a remote boot environment to control access to the operating systems offered by the server. In other words, the administrator should have the capability to prevent booting by unauthorized users, prior to the loading of the operating system. Security products exist in the marketplace to prevent unauthorized booting; however, a need exists for a security program that is administered solely at the server level. Thus, no security file would be kept on the client system. Present remotely administered pre-boot security systems, require the security file to be downloaded to the client system after the system has been booted. A need exists for a system that can operate without such a requirement.
Moreover, given the capability of RIPL/PXE boot environment, a need cxists for a security logon system that can also provide specific work station environments to the client machine, based on user ID. For example, if a user is a bank teller, anytime that user boots a system, regardless of which physical system it is, the user would receive a xe2x80x9cteller""sxe2x80x9d system. Alternatively, if the user were identified as an administrator, the user would receive an admrinistrator""s package. The Remotcly Controllcd Boot Manager (BCB comprises a set of programs at the workstation and as menu control program at the server.
The invention meeting the needs identified above is a PRE-EXECUTION LOGON (PEL) which provides an apparatus and method to allow a server in a LAN environment to validate a user""s ID and password prior to booting a client system. When the client system is started, PEL will present a logon screen to the user. The logon information will be sent to a server application that will validate the information and either allow a boot, on the client, or not. In addition, in a RIPL/PXE boot environment, PEL can provide a specific system xe2x80x9cpersonalityxe2x80x9d to the user regardless of which physical client machine the user is using. PEL augments LAN system security by preventing client systems from booting when the user is unknown to the server. Other security systems require an operating system to be loaded in the client machine before a logon can be started. PEL""s advantage, as a security feature, is that it prevents booting by unauthorized users, prior to the loading of the operating system. When used in a RIPL/PXE boot environment, PEL can also provide specific work station environments to the client machine, based on user ID. PEL, when used with the Remotely Controlled Boot, allows an adminstrator to customize a system personality, by user ID. In other words, regardless of which machine the user logs on to, the user will get the specific system set up for him him by the adminstrator.
The first part of the process is to set up the capability for remote booting. In the preferred embodiment, a set of programs at the workstation allows a remote boot and interaction with a program on the server. Instructions from a Basic Input Output System (BIOS) ROM are executed to load a Boot Code Loader (BCL) from a nonvolatile, read/write memory, such as a diskette or hard disk. The BCL executes to load a Remote Control Program (RCP), and the RCP executes to load a message program, a protocol manager and/or device drivers without loading an operating system. The message program and/or device drivers communicate with a PRE-EXECUTION LOGON (PEL) program in the network server. First, the program will interface with an NDIS compliant Network Interface Card (NIC) to send out a PEL discovery frame. The discovery frame will be intercepted by a PEL program installed on a server which will be running and listening for the request. Once the PEL program intercepts the request it will present a logon screen to the workstation user. The user will enter his or her user identification and password. The PEL will validate the user identification number and password. Upon validation the server, will either send a boot operating system which is not specifically assigned to that user identification or the server will send an LAA to the client workstation based on an assignment by the administrator. The client workstation will then request an operating system with its new LAA. The boot options will be a table or pool corresponding to an LAA or range of LAA""s. In other words, a particular boot option or package will be sent to a system making a request that has the corresponding LAA. In order to achieve the override of the UAA the PEL will assign an LAA to the workstation. Once the LAA, is assigned the boot will proceed based on the package that will be shipped to that address.